Hardware Description Languages (HDLs), such as the Very high-speed integrated circuit Hardware Description Language (VHDL) or Verilog, are text-based approaches to digital logic design. They allow both behavioral and structural descriptions of design elements. HDL can be used to design: (1) a programmable logic device (PLD), such as a field programmable gate array (FPGA) or complex programmable logic device (CPLD); (2) a mask programmable device, such as a hardwired pin grid array (PGA), application-specific standard product (ASSP) or application specific integrated circuit (ASIC); (3) a system formed from selected electronic hardware components; or (4) any other electronic device. The HDL-based approach to design requires the user to describe the behavior of a system, which can then be simulated to determine whether the design will function as desired. The design is then synthesized to create a logical network list (“netlist”) that can be implemented within a particular device.
Many tools exist that allow electronic designs of integrated circuits (ICs) to be assembled, simulated, debugged, and translated into hardware. Some such tools, known as high-level modeling systems (HLMSs), allow IC designs to be described and simulated in a high level and abstract environment, then translated automatically into working electronic hardware. Often an HLMS writes HDL files to describe the hardware it produces.
One approach to producing HDL files from an HLMS is to employ text files known as “HDL templates”. An HDL template consists largely of ordinary fixed HDL constructs, but also contains variable portions that are “tailored” by the HLMS to match the particulars of the design. Typically the variable portions describe names and numbers of ports, values of parameters, and details of subsidiary blocks. Once a template has been tailored, it becomes a functioning HDL description of a portion of an electronic IC design that may be simulated or synthesized.
FIG. 1 depicts an exemplary VHDL template 100 that may be used to implement multipliers. Template 100 includes a fixed portion 101 and a variable portion 102. The variable portion 102 includes placeholders 105 that are indicated using particular delimiters, such as angled brackets 103 or an HDL comment 104. Notably, the variable portion 102 includes <entity name>, <component name>, <c_a_width>, and <c_b_width> placeholders 105, as well as the “--Port needed only when registered” comment 105. A specific multiplier may be realized in HDL by tailoring template 100. The placeholders 105 within the variable portion 102 are substituted with values, or deleted, as necessary.
One way that an HLMS can tailor templates is by using custom text processing software. This approach, however, has several drawbacks. An HLMS usually provides a broad and varied collection of design building blocks, and the collection usually grows as the HLMS is augmented and developed. Each building block typically has several associated HDL templates, and the kinds of tailoring that are needed may vary considerably. An HLMS may make it possible for a user or a third party to augment the collection with custom building blocks, in which case it is impossible to anticipate all the varieties of tailoring that might be needed. For these reasons it is difficult to write custom text processing software for an HLMS. At the same time, powerful free software tools, such as Perl, Python, sed, and awk, are well suited to handling text processing problems in general. Occasionally, tailoring a template requires the full power of such general-purpose tools, but more often the problems are simple, and a simpler approach is desirable.
Therefore, there exists a need to avoid or reduce the number of custom text processors employed to tailor HDL templates in an HLMS, instead using general-purpose text processing tools.